Multiple network protocol encoder/decoder and data processor

ABSTRACT

A multiple network protocol encoder/decoder comprising a network protocol layer, data handler, O.S. State machine, and memory manager state machines implemented at a hardware gate level. Network packets are received from a physical transport level mechanism by the network protocol layer state machine which decodes network protocols such as TCP, IP, User Datagram Protocol (UDP), PPP, and Raw Socket concurrently as each byte is received. Each protocol handler parses and strips header information immediately from the packet, requiring no intermediate memory. The resulting data are passed to the data handler which consists of data state machines that decode data formats such as email, graphics, Hypertext Transfer Protocol (HTTP), Java, and Hypertext Markup Language (HTML). Each data state machine reacts accordingly to the pertinent data, and any data that are required by more than one data state machine is provided to each state machine concurrently, and any data required more than once by a specific data state machine, are placed in a specific memory location with a pointer designating such data (thereby ensuring minimal memory usage). Resulting display data are immediately passed to a display controller. Any outgoing network packets are created by the data state machines and passed through the network protocol state machine which adds header information and forwards the resulting network packet via a transport level mechanism.

BACKGROUND OF THE INVENTION

1. Technical Field

The invention relates to network protocols and data packets. Moreparticularly, the invention relates to the decoding of network protocolsand processing of packet data during packet reception without thetime-consuming overhead of software or software/hardwareimplementations. In addition, the invention allows one pass parsing ofthe data, eliminating the buffering of data packets for differentstacks, and thus minimizing the memory usage.

2. Description of the Prior Art

Computer networks necessitate the provision of various communicationprotocols to transmit and receive data. Typically, a computer networkcomprises a system of devices such as computers, printers and othercomputer peripherals, communicatively connected together. Data aretransferred between each of these devices through data packets which arecommunicated through the network using a communication protocolstandard. Many different protocol standards are in current use today.Examples of popular protocols are Internet Protocol (IP), InternetworkPacket Exchange (IPX), Sequenced Packet Exchange (SPX), TransmissionControl Protocol (TCP), and Point to Point Protocol (PPP). Each networkdevice contains a combination of hardware and software that translatesprotocols and process data.

An example is a computer attached to a Local Area Network (LAN) system,wherein a network device uses hardware to handle the Link Layerprotocol, and software to handle the Network, Transport, andCommunication Protocols and information data handling. The networkdevice normally implements the one Link Layer protocol in hardware,limiting the attached computer to only that particular LAN protocol. Thehigher protocols, e.g. Network, Transport, and Communication protocols,along with the Data handlers, are implemented as software programs whichprocess the data once they are passed through the network devicehardware into system memory. The advantage to this implementation isthat it allows a general purpose device such as the computer to be usedin many different network setups and support any arbitrary networkapplication that may be needed. The result of this implementation,however, is that the system requires a high processor overhead, a largeamount of system memory, complicated configuration setup on the part ofthe computer user to coordinate the different software protocol and datahandlers communicating to the computer's Operating System (O.S.) andcomputer and network hardware.

This high overhead required in processing time is demonstrated in U.S.Pat. No. 5,485,460 issued to Schrier et al on Jan. 16, 1996, whichteaches a method of operating multiple software protocol stacksimplementing the same protocol on a device. This type of implementationis used in Disk Operating System (DOS) based machines running MicrosoftWindows. During normal operation, once the hardware verifies thetransport or link layer protocol, the resulting data packet is sent to asoftware layer which determines the packets frame format and strips anyspecific frame headers. The packet is then sent to different protocolstacks where it is evaluated for the specific protocol. However, thepacket may be sent to several protocols stacks before it is accepted orrejected. The time lag created by software protocol stacks prevent audioand video transmissions to be processed in real-time; the data must bebuffered before playback. It is evident that the amount of processingoverhead required to process a protocol is very high and extremelycumbersome and lends itself to applications with a powerful CentralProcessing Unit (CPU) and a large amount of memory.

Consumer products that do not fit in the traditional models of a networkdevice are entering the market. A few examples of these products arepagers, cellular phones, game machines, smart telephones, andtelevisions. Most of these products have small footprints, 8-bitcontrollers, limited memory or require a very limited form factor.Consumer products such as these are simplistic and require low cost andlow power consumption. The previously mentioned protocol implementationsrequire too much hardware and processor power to meet theserequirements. The complexity of such implementations are difficult toincorporate into consumer products in a cost effective way. If networkaccess can be simplified such that it may be easily manufactured on alow-cost, low-power, and small form-factor device, these products canaccess network services, such as the Internet.

SUMMARY OF THE INVENTION

The invention provides a low-cost, low-power, easily manufacturable,small form-factor network access module which has a low memory demandand provides a highly efficient protocol decode. The invention comprisesa hardware-integrated system that both decodes multiple networkprotocols in a byte-streaming manner concurrently and processes packetdata in one pass, thereby reducing system memory and form factorrequirements, while also eliminating software CPU overhead.

The preferred embodiment of the invention comprises a network protocollayer, data handler, O.S. State Machine, and memory manager statemachines implemented at a hardware gate level. Network packets arereceived from a physical transport level mechanism by the networkprotocol layer state machine. The protocol state machine decodes networkprotocols such as TCP, IP, User Datagram Protocol (UDP), PPP, and RawSocket concurrently as each byte is received. Each protocol handlerparses, interprets, and strips header information immediately from thepacket, requiring no intermediate memory. The resulting data are passedto the next protocol layer or data handler for which the latter caseconsists of data state machines that decode data formats such as email,graphics, Hypertext Transfer Protocol (HTTP), Java, and Hypertext MarkupLanguage (HTML). Each data state machine reacts accordingly to thepertinent data, and any data that are required by more than one datastate machine are provided to each state machine concurrently. Any datathat are required more than once by a specific data state machine, areplaced in a specific memory location with a pointer designating suchdata (thereby ensuring minimal memory usage). Resulting display data areimmediately passed preformatted to a display controller. Any outgoingnetwork packets are created by the data state machines and passedthrough the network protocol state machine which adds formats to thepacket, and checksums the information header information, and forwardsthe resulting network packet via a physical transport level mechanism.

The preferred embodiment does not necessarily require a CPU and softwareto process the network packets, thereby greatly reducing system cost.The hardware gate level implementation provides a modular, embeddabledesign whereupon the designer may pick and choose the functionality thatthe particular application requires and still retain a low cost, lowpower, small form factor.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a high-level data flow diagram of the core system according tothe invention;

FIG. 2 is a high-level block diagram of a system according to theinvention;

FIG. 3 is a functional block diagram of a complete system implementationaccording to the invention;

FIG. 3A is a functional block diagram of the UMA memory controlleraccording to the invention;

FIG. 4 is a time comparison chart illustrating data task timerequirements for a traditional architecture and the invention.

FIG. 5 illustrates the possible progression of applications according tothe invention;

FIG. 6 illustrates the concept of an Internet Tuner according to theinvention;

FIG. 7 illustrates two implementations according to the invention;

FIG. 8 illustrates Network PC implementations according to theinvention;

FIG. 9 illustrates Handheld Devices implementations according to theinvention;

FIG. 10 illustrates Smart Telephone implementations according to theinvention;

FIG. 11 illustrates Smart Television, cable-box, Video Cassette Recorder(VCR), Digital Video Disc (DVD) and game machine implementationsaccording to the invention; and

FIG. 12 is a timing diagram sharing a received packet according to theinvention; and

FIG. 13 is a block schematic diagram showing signal flow for the packetof claim 12 according to the invention.

DETAILED DESCRIPTION OF THE INVENTION

Referring to FIG. 1, the invention comprises a Network Protocol Layer101, a Data Handler 102, a Memory Control module 103, and an OperatingSystem (O.S.) State Machine module 104, each implemented at the hardwaregate level. The Network Protocol Layer 101 decodes incoming and encodesoutgoing network packets. The Network Protocol Layer 101 comprises aplurality of state machines representing different network protocolstacks (i.e. PPP, TCP, IP, UDP, and Raw Socket) which simultaneouslydecode incoming network packets. The implementation of the protocolstacks in gate level logic allows the real time decoding of the networkpacket as the packet is received, thereby requiring no temporary memorystorage. After all of the packet header information is stripped out andverified by the state machines, the resulting data is passed to the DataHandler 102. The Data Handler 102 comprises a plurality of statemachines, each of which process a specific data type (i.e. HTTP, emailformats (Post Office Protocol (POP3), Internet Message Access Protocol(IMAP4), Simple Mail Transfer Protocol (SMTP)), graphics standards(Joint Photographic Experts Group (JPEG), Graphics Interchange Format(GIF)), Java, and HTML). The gate level implementation of the datahandlers enable the invention to concurrently process received data inreal time and is especially suitable for applications which handlestreams of data as they are received, i.e. Java, HTML, POP3 email, andaudio and video applications. Any data that are required by more thanone data state machine are provided in a concurrent manner. Any datarequired more than once by a specific data state machine are placed in aspecific memory location with a pointer designating them. All memoryaccesses are arbitrated through the Memory Control module 103. Anyresulting display data are also routed through the Memory Control module103. The O.S. State Machine 104, acts as an arbitrator between all ofthe state machines for resource control, system, and user interface. Anyuser input is interpreted by the O.S. State Machine and routed to theData Handler 102.

As an example, a data handler that interprets HTML format could decodethe HTML tags using a Cyclic Redundancy Check (CRC) calculation. HTMLformat contains character strings known as tags, which control theformatting of a subsequent block of text when displayed on a videooutput device. These tags may be efficiently decoded by generating a CRCnumber for a given tag and using said number to enable a formattinginstruction. Such a decoding algorithm is suited for gate levelimplementation and provides for an HTML encoded document to be displayedon a video output device much more quickly than is currently possible.

Although the invention is described as being at the hardware gate level,one skilled in the art can readily appreciate that these functions maybe implemented in many other ways such as Programmable Array Logic(PALs), General Array Logic (GALs), Read Only Memory (ROMs), andsoftware. Additionally, specific protocols and data types have beenindicated and one skilled in the art can readily appreciate that themodularity of the invention does not limit it to those specificprotocols or data types.

Turning to FIG. 2, the invention is represented in a high-level blockdiagram. This diagram describes the operational task of each module in afull implementation of the invention. The O.S. State Machine 208,contains the system “glue” logic, and the device control interface, andacts as a “traffic cop” between the state machines of the other modules.The Network Protocol Layer 207, contains state machines for TCP/IP, UDP,Raw Socket, and PPP protocols. The Memory Control module 206 containsthe logic for the Unified Memory Architecture (UMA) which allows thesystem and video display memory to reside in the same memory area. ADisplay Controller 205 provides control of a VGA, television standard,or other type of display. Four data handlers are used in thisimplementation. An Email data handler 201 interprets both POP3 and IMAP4formats. Interpreters 202 are implemented which decode JPEG and GIFformats (commerce and telephony standards may also be decoded). A JavaMachine 203 is also included which interprets the Java language bytecodes. The World-Wide Web (WWW) Browser 204, contains an HTMLdecoder/accelerator, HTTP Data handler and an integrated email statemachine.

As an example, an incoming JPEG image packet is traced through thesystem, assuming a MODEM physical transport. The request starts with theuser indicating a desire to download a given JPEG image by typing onkeyboard 321. This input is interpreted by the keyboard interface 316and passed to the O.S. State machine 315. O.S. State machine 315processes the input and passes it as a command to the HTTP client 311.The HTTP client creates a request packet and passes it via the PortDecoder 309 to the TCP Layer 308. The TCP Layer prepends the appropriateTCP header and passes it to the IP Layer 307. The IP layer then prependsthe appropriate IP header and passes the packet to the PPP layer 306.The PPP Layer prepends the appropriate header, appends an FCS, andpasses the data to the Physical Transport Interface 305. The PhysicalTransport Interface serializes the data into a bit stream and sends thepacket to the MODEM unit 304. When the request is accepted by the hostserver, it sends the requested JPEG image back to the client system. Thedata are first received by the MODEM 304 which indicates to the PhysicalTransport Interface 305 that data are present. The Physical Transportinterface then reads the bit serial data from the MODEM, converts it toa parallel byte data, and indicates to the PPP Layer 306 that data arepresent. The PPP Layer reads in the received bytes. When it detects avalid start byte, it begins to parse the incoming bytes. When the bytestream reaches the PPP protocol field, the PPP Layer decodes it, and inthis example decodes the embedded packet as being of type IP. Inresponse to this protocol byte, the PPP Layer enables the IP Layer 307and indicates to it that IP data are being received. All further databytes received are now passed directly to the IP Layer. The IP Layerthen begins to parse the incoming data bytes. When it comes to the IPheader protocol field, it determines which higher protocol to enable. Inthis example, the IP Layer decodes the protocol field as being of typeTCP. At this point, the IP Layer enables the TCP Layer 308 and indicatesto it when TCP data are being received. When this indicator goes active,all further data bytes in the received packets are sent to both the IPand TCP Layers (IP Layer needs the data bytes to complete checksumcalculations). The TCP Layer then begins to parse the incoming databytes. When it comes to the TCP header destination port field, itdetermines which data handler to enable. In this example, the PORT fielddecodes to the HTTP client 311. At this point, the PORT decoder enablesthe HTTP client and indicate to it that HTTP requested data are beingreceived. The HTTP client then begins to parse received data bytes. Whenthe HTTP client determines that the packet is of type JPEG image, theHTTP client enables the JPEG decoder 313. At this point, all data bytesare now routed to the JPEG decoder. The JPEG decoder then receives allfurther incoming data bytes and processes them accordingly. Theresulting decoded image is sent to the display memory via the MemoryController 312 to be processed by the Display Controller 324 for outputto display device 326.

As also noted in FIG. 3, various layers need access to a shared memoryresource. All memory accesses are arbitrated by a single memorycontroller. This memory controller determines which layer or handler hasaccess at any given cycle to the unified memory buffer. This memorycontroller is needed due to the fact that all system and display memorybuffers are shared within a single memory buffer unit. The unifiedmemory controller 312 takes read and write requests from the variouslayers, arbitrates the requests based on a dynamic rotating arbitrationscheme with fixed priority weighting. This algorithm is depicted in FIG.3A. If, in the pictured configuration, device D2 302A and device D3 303Aboth request memory access at the same time, then the arbitor 307Aawards the cycle to the device that has not had the most recent memoryaccess. The arbitor 307A then passes its memory request to the A inputarbitor 309A. If the B input on arbitor 309A is idle, then the requestis passed up to the B input of arbitor 310A. If the A input to thearbitor 310A is idle, then the request is made to the memory unit. Allarbitration determinations are performed using combinatorial logic,thereby eliminating any wait states to any device if no other memoryrequests are being made. Priority weighting is assigned by configuringthe arbitration tree structure. In FIG. 3A, Device DO 300A and Device D1301A each have 25% priority weighting meaning that if all devicesrequested constant memory usage, they would each win the arbitration 25%of the time. Devices D2 302A, D3 303A, D4 304A, and D5 305A each have12.5% priority weighting. The memory controller design is simplified byhaving each of the individual arbitration units having the same logicstructure. In this scheme, the number of requesting devices, and theirpriority weighting can easily be configured by adding and arrangingarbitor units.

Turning to FIG. 4, the speed advantages that the invention offers aremuch higher than the traditional architecture currently in use. Thefigure represents the time needed to complete each task. For a series ofpackets that require an HTML download 401, decode of the HTML 402, JPEGdownload 403, decode of the JPEG 404, JAVA download 405, decode of theJAVA bytes 406, and streaming audio 407, the total time required forthese tasks is shown for the traditional architecture 408 and theinvention (iReady architecture) 409. The invention 409 is significantlyfaster for these tasks than the traditional architecture 408.

Turning to FIG. 5, the progression of applications for this type ofnetwork access is shown. Presently, the traditional model of the networkclient is being used, namely the computer 501. The consumer applianceconcepts of the Network PC 502, handheld devices 503, smart telephones504, set-top appliances 505, and smart televisions 506 are now becominga reality. The invention provides these products with a cost-effective,space, speed, and power conscious network access.

Referring to FIG. 6, the invention operates much like a television 602or radio tuner 611—the signals (packets) are processed immediatelywithout delay and sent to a display or audio output. The term InternetTuner 608 is used to describe the invention as an analogy to such signalprocessing devices. The Internet Tuner 608 acts as the interface betweenthe Internet signals 609 and application products such as smarttelevisions 604, set-top appliances 605, smart telephones 606, andhandheld devices 607. It processes Internet signals 609 in real-time asdo television 602 and radio tuners 611.

FIG. 7 illustrates that a full implementation of the invention using theO.S. State Machine 701, Network Protocol Layer 702, Memory Control 703,Display Controller 704, email data handler 708, Interpreters 707, JavaMachine 706, and WWW Browser 705 may be separated into two separatemodules. The modularity of the invention allows functions such as thedata handlers 713 (email data handler 717, Interpreters 716, JavaMachine 715, and WWW Browser 714) to be separated and placed into ahigh-level ROM code for certain applications.

The following application examples further illustrate the versatility ofthe modular design of the invention.

FIG. 8 demonstrates the possible configurations of the invention for aNetwork PC. One variation includes the O.S. State Machine 801, NetworkProtocol Layer 802, Memory Control 803, Display Controller 804, emaildata handler 808, Interpreters 807, Java Machine 806, and the WWWBrowser 805. This can be varied by placing the data handlers for email817. Interpreters 816, Java Machine 815, and WWW Browser 814 code intohigh-level ROM running on a microprocessor 813. The microprocessor 813communicates through the O.S. State Machine 809 for network and displayfunctions. A third variation allows a microprocessor 822 running off ofa 3rd Party ROM 823 to interpret the data coming from the NetworkProtocol Layer 819 and O.S. State Machine 818. The microprocessor 822displays data through the Display Controller 821.

Turning to FIG. 9, a handheld device may use only the Network ProtocolLayer 901 and interface it to a custom Transport Mechanism 902 andExisting Microcontroller 904. Email functions may be added by includingthe email data handler 905 in the configuration. Further demonstratingthe modularity of the invention, the Network Protocol Layer 911 and JavaMachine 910 may be added to a handheld device, thereby allowing it toprocess Java applets.

Referring to FIG. 10, smart telephones may add email capabilities byimplementing the O.S. State Machine 1001, Network Protocol Layer 1002,Memory Control 1003, email data handler 1006, and Display Controller1004. The Display Controller 1004 is capable of controlling LightEmitting Diode (LED), Liquid Crystal Display (LCD) displays, orbig-mapped displays. A Physical Transport Control 1005 may optionally beadded, depending on the connectivity requirements of the smarttelephone. The O.S. State Machine 1007, Network Protocol Layer 1008, andMemory Controller 1009 may be added to smart telephones with an existingmicrocontroller 1010. The microcontroller 1010 performs email functionsusing a 3rd Party email client code 1011.

Turning finally to FIG. 11, smart televisions, cable-boxes, VideoCassette Recorders (VCRs), Digital Video Disc (DVD) players, and gamemachines can take advantage of the network accessibility offereNety theinvention. The O.S. State Machine 1102, Network Protocol Layer 1103,Memory Controller 1104, WWW Browser 1107, Java Machine 1106, and(optionally) the Display Controller 1105 are interfaced to an existingcontroller 1101. If a controller 1101 is not present, the DisplayController 1105 is used. Email 1115 functions are easily added due tothe modularity of the invention. As noted previously, the data handlersfor email 1124, Interpreters 1123, Java Machine 1122, and WWW Browser1121 code are optionally placed into high level ROM running on amicroprocessor 1120. The microprocessor 1120 communicates through theO.S. State Machine 1116 for network and display functions.

Example of Packet Reception

FIG. 12 depicts a received network packet. The packet contains thefollowing items as shown from left to right:

PPP header

IP header

TCP header

JPEG Data

PPP FCS (Field Checksum)

The line labeled PPP LAYER ENABLE is activated when a valid start byteis detected, and is generated within the PPP block in FIG. 13. Once thisline goes high, the rest of the PPP block is activated. Within the PPPheader is a field indicating the type of protocol that the PPP packet isencapsulating. In an uncompressed PPP header, these are bytes 4 and 5(counting the start byte 0×7e). In FIG. 12, these bytes are 0×00 and0×21 indicating that the encapsulated data is an IP packet. Afterdecoding this field, the PPP block activates the IP LAYER ENABLE and PPPDATA FIELD signals, which together enable the IP block in FIG. 13. TheIP LAYER ENABLE line is decoded from the PPP protocol field, and the PPPDATA FIELD line indicates that the incoming data byte stream is in thedata field portion of the network packet. These two lines must be activefor the IP block to be enabled. Once the IP block is enabled, it startsto parse the incoming data bytes. Referring back to FIG. 12, the dataimmediately following the PPP header is the IP header. Within the IPheader is a field indicating the type of data that is encapsulatedwithin the IP packet. In FIG. 12, this field is shown to be 0×06indicating that the encapsulated data is a TCP packet. The TCP LAYERENABLE line is activated in response to the IP block decoding thisfield. The IP DATA FIELD line goes active a couple of bytes later,because there are some bytes that come between the IP header protocolfield and the start of the IP data field. The IP DATA FIELD signalindicates that the incoming data byte streams is in the data fieldportion of the network packet. Both the TCP LAYER ENABLE and IP DATAFIELD lines must be active in order for the TCP block in FIG. 13 to beenabled. Once the TCP block is enabled, it starts to parse incoming databytes. Referring back to FIG. 12, the data immediately following the IPheader is the TCP header. Within the TCP header is a 2 byte field forthe destination port. This field indicates which application or datahandler the encapsulated data is meant for. In FIG. 12, this fielddecodes to port 0×0003. In FIG. 13, port 3 is designated as the HTTPport. After decoding the destination port field within the TCP header,the HTTP ENABLE line is activated. The TCP DATA FIELD line is activateda couple of bytes later because there are some intermediate bytesbetween the destination port field and the start of the TCP data field.Both the HTTP ENABLE and TCP DATA FIELD lines must be active for theHTTP/PORT3 block in FIG. 13 to be enabled. Once the HTTP block isenabled, it starts to parse incoming data bytes. When it decodes theJPEG header, it enables the JPEG decoder block in FIG. 13. Once the JPEGdecoder is enabled, it starts to process incoming bytes. The JPEG enableline is the only line needed to enable the JPEG block.

Although the invention is described herein with reference to thepreferred embodiment, one skilled in the art will readily appreciatethat other applications may be substituted for those set forth hereinwithout departing from the spirit and scope of the present invention.Accordingly, the invention should only be limited by the Claims includedbelow.

1. An apparatus for decoding and encoding network protocols and data,comprising: a network protocol layer module for receiving andtransmitting network packets and for encoding and decoding networkpackets bytes which comprise packet data; a data handler module forexchanging said packet data with said network protocol layer module andfor processing a at least one specific data type or protocol; a memorycontrol module in communication with said data handler module forarbitrating memory accesses and for providing display data ; and anoperating system (o.s.)at least one state machine module that isoptimized for a single selected network protocol, said o.s.at least onestate machine module in communication with said data handler module andproviding resource control and system and user interfaces ; wherein saidnetwork protocol layer module, said data handler module, said memorycontrol module, and said operating system (o.s.) at least one statemachine module comprise corresponding dedicated hardware structures thatare implemented in hardware gate level circuitry.
 2. The apparatus ofclaim 1, wherein said network protocol layer module comprises aplurality of state machines representing different network protocolsstacks.
 3. The apparatus of claim 2 1, wherein said network protocollayer module implements one or more of the following network protocols:Point to Point Protocol (PPP), Internetwork Packet (IP), TransmissionControl Protocol (TCP), Raw Socket, and/or User Datagram Protocol (UDP).4. The apparatus of claim 2 1, wherein said network packets bytes areprocessed in real time.
 5. The apparatus of claim 2 1, wherein saidnetwork packets bytes are processed concurrently.
 6. The apparatus ofclaim 2 1, wherein said network packets bytes are processed byte-serially.
 7. The apparatus of claim 1, wherein any data required morethan once by a specific said state machine is placed in a specificmemory location with a pointer designating said memory location.
 8. Theapparatus of claim 1, wherein said data handler module comprises atleast one state machine which processes a specific data type.
 9. Theapparatus of claim 8, wherein said data handler module processes one ormore of the following protocols: Hypertext Transfer Protocol (HTTP),Hypertext Markup Language (HTML), Post Office Protocol (POP3), InternetMessage Access Protocol (IMAP4), Simple Mail Transfer Protocol (SMTP),Joint Photographic Experts Group (JPEG), Graphics Interchange Format(GIF), and/or Java language.
 10. The apparatus of claim 8, wherein saiddata type is processed in real time.
 11. The apparatus of claim 8,wherein said data type is processed concurrently.
 12. The apparatus ofclaim 8, wherein said data type is processed byte serially.
 13. Theapparatus of claim 8, wherein any data shared by said at least one statemachine or required more than once by a specific said state machine isplaced in a specific memory location with a pointer designating saidmemory location.
 14. The apparatus of claim 8, wherein any data sharedby said at least one state machine is provided to said state machine(s)concurrently.
 15. The apparatus of claim 1, wherein said memory controlmodule arbitrates all memory accesses.
 16. The apparatus of claim 1,wherein said memory control module contains a Unified MemoryArchitecture (UMA) which allows a system memory and a video memory toreside in a same memory area.
 17. The apparatus of claim 1, wherein saidmemory control module is comprised of one or more arbiter logic blockswhere an arbiter block arbitrates according to a dynamic rotatingalgorithm between two devices.
 18. The apparatus of claim 1, whereinsaid memory control module is comprised of one or more arbiter logicblocks arranged in such a manner as to give a fixed weighted priority toeach of a plurality of devices for memory access based on a givenarbiter tree structure.
 19. The apparatus of claim 1, wherein said o.s.further comprising an arbitrator state machine that acts as anarbitrator between said network protocol layer module, said data handlermodule, and said memory control module for resource control, system anduser interface.
 20. The apparatus of claim 1, further comprising: adisplay controller.
 21. The apparatus of claim 20, wherein said displaycontroller controls one of the following types of displays: VGA,television, Liquid Crystal Display (LCD), or Light Emitting Diode (LED).22. The apparatus of claim 1, wherein said apparatus acts as aninterface between Internet signals and application products byprocessing Internet signals in real-time and sending said processedInternet signals to said application products.
 23. A process fordecoding and encoding network protocols and data, said processcomprising the steps of: providing a network protocol layer module forreceiving and transmitting network packets and for encoding and decodingnetwork packets bytes which comprise packet data; providing a datahandler module for exchanging said packet data with said networkprotocol layer module and for processing a at least one specific datatype or protocol; providing a memory control module in communicationwith said data handler module for arbitrating memory accesses and forproviding display data ; and providing an operating system (o.s.) atleast one state machine module that is implemented in hardware and thatis optimized for a single selected network protocol, said o.s. at leastone state machine module in communication with said data handler moduleand providing resource control and system and user interfaces ; whereinsaid network protocol layer module, said data handler module, saidmemory control module, and said operating system (o.s.) at least onestate machine module comprise corresponding dedicated hardwarestructures that are implemented in hardware gate level circuitry. 24.The process of claim 23, wherein said step of encoding and decodingnetwork packet bytes network protocol layer module further comprises thestep of: representing different network protocols stacks using aplurality of state machines.
 25. The process of claim 24, wherein saidstep of encoding and decoding network packet bytes network protocollayer module further comprises the step of: encoding and decoding one ormore of the following network protocols: Point to Point Protocol (PPP),Internetwork Packet (IP), Transmission Control Protocol (TCP), RawSocket, and/or User Datagram Protocol (UDP).
 26. The process of claim23, wherein said network protocol layer module step of encoding anddecoding network packet bytes further comprises the step of: processingnetwork packets bytes in real time.
 27. The process of claim 23, whereinsaid step of encoding and decoding network packet bytes network protocollayer module further comprises the step of: processing network packetsbytes concurrently.
 28. The process of claim 23, wherein said step ofencoding and decoding network packet bytes network protocol layer modulefurther comprise the steps of: processing network packet bytes packetsin a byte serial fashion.
 29. The process of claim 23, wherein said stepof processing packet data bytes data handler module further comprisesthe step of: processing specific data type(s) using at least one statemachine.
 30. The process of claim 29, wherein said step of processingpacket data bytes data handler module further comprises the step of: useof a CRC algorithm to decode data fields.
 31. The process of claim 29,wherein said step of processing packet data bytes data handler modulefurther comprises the step of: processing one or more of the followingprotocols: Hypertext Transfer Protocol (HTTP), Hypertext Markup Language(HTML), Post Office Protocol (POP3), Internet Message Access Protocol(IMAP4), Simple Mail Transfer Protocol (SMTP), Joint PhotographicExperts Group (JPEG), Graphics Interchange Format (GIF), and/or Javalanguage.
 32. The process of claim 29, wherein said step of processingpacket data bytes data handler module further comprises the step of:processing packet data bytes in real time.
 33. The process of claim 29,wherein said step of processing packet data bytes data handler modulefurther comprises the step of: processing packet data bytesconcurrently.
 34. The process of claim 29, wherein said step ofprocessing packet data bytes data handler module further comprises thestep of: processing packet data bytes in a byte serial fashion.
 35. Theprocess of claim 29, wherein said step of processing packet data bytesdata handler module further comprises the step of: placing any data morethan once by a specific one of said at least one state machine in aspecific memory location with a pointer designating said memorylocation.
 36. The process of claim 23, wherein said step of controllingmemory accesses further comprises the step of: memory control modulearbitrating es all memory accesses.
 37. The process of claim 23, whereinsaid step of controlling memory accesses further comprises the step of:memory control module allowing s a system memory and a video memory toreside in a same memory area using a Unified Memory Architecture (UMA).38. The process of claim 23, wherein said step of controlling statemachine sequencing further comprises ing the step of: arbitratingbetween said step of encoding and decoding network packet bytes networkprotocol layer module, said step of processing packet data bytes datahandler module, and said step of controlling memory accesses memorycontrol module for resource control, system and user interface.
 39. Theprocess of claim 23, wherein said step of controlling state machinesequencing further comprises ing the step of: interpreting system anduser input for the purpose of controlling data handler modules andnetwork protocol layer modules.
 40. The process of claim 23, furthercomprising the step of: displaying output data.
 41. The process of claim40, wherein said step of displaying output data further comprises thestep of: controlling one of the following types of displays: VGA,television, Liquid Crystal Display (LCD), or Light Emitting Diode (LED).42. The process of claim 23, wherein said process is used to implementan interface between Internet signals and application products byprocessing Internet signals in real-time and sending said processedInternet signals to said application products.
 43. The apparatus ofclaim 1, wherein said memory control module provides display data. 44.The process of claim 23, wherein said memory control module providesdisplay data.